-
Notifications
You must be signed in to change notification settings - Fork 121
Update WC plugin matching to use the file name in plugin path: use cases that match plugin by name - part 1 #15938
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update WC plugin matching to use the file name in plugin path: use cases that match plugin by name - part 1 #15938
Conversation
…l stays internal.
…a plugin synchronously.
…h test cases on the change.
…oadPluginInStorage`.
|
|
…ller.isSourceTypeAvailable(.camera)`.
staskus
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! 👍 Tested installing the plugins in the enum and the check works correctly
| import Foundation | ||
|
|
||
| public enum Plugin: Equatable, CaseIterable { | ||
| case wooCommerce |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great idea to make an enum for consistency 👍

Part 1 of WOOMOB-913
Just one review is required.
Description
This PR is part 1 of updating plugin matching to use the file name in plugin path instead of matching by plugin name. This change addresses edge cases where plugin paths can be altered by certain hosts or other plugins.
This PR removes a subset of plugin matching by name use cases across the app and replaces them with a more robust plugin matching approach using the
PluginsService.loadPluginInStoragemethod with a plugin enum. The changes include:Key changes:
loadSystemPlugin(siteID:name:)and related use cases in order detailsPluginenum to centralize plugin matching logic and keep implementation details internal within YosemitePluginsServicewithloadPluginInStoragemethod that accepts a plugin enum for synchronous plugin loadingProductListViewModelto remove plugin matching by name use case, with test cases for the changesOrderDetailsViewModelto use the new plugin enum approach instead of name-based matchingSystemStatusAction.fetchSystemPluginListWithNameListusage across the codebasePluginsServiceImplementation details
The implementation moves away from fragile name-based plugin matching towards a more durable approach that will support filename-based matching in subsequent PRs. The
Pluginenum provides a centralized way to identify plugins while keeping the matching implementation details internal to the service layer.Steps to reproduce
Since this is a refactoring change that maintains existing functionality:
Testing information
I tested:
ProductListViewModelchanges for sites with and without Woo Square pluginRELEASE-NOTES.txtif necessary.